Related: #1245

Very cool, thanks for sharing! There will be lots of challenges to making the inferred typing accurate. There is also:

• .storeOptionsAsProperties(false)
• .opts()
• .addOption() Enhance Option class to allow hiding help, specifying choices, and change how default value displayed in help #1331

Removing the option-keys from the program type when .storeOptionsAsProperties(false) would be a big win on its own, as there is currently no TypeScript assistance for detecting incorrect routine names because of the generic typing for the option-keys.

Another challenge is the --no- prefix. The way I'm doing this now, where the extracted type of each .option call is &ed with this ends up breaking if you have both --cheese and --no-cheese. It ends up doing { cheese?: string | true } & { cheese?: boolean }, which typescript merges as { cheese?: undefined }. We'd need to use something like this stackoverflow answer, but hopefully simpler.

For interest, I did some quick research on whether possible to support multiple versions of TypeScript

• https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions

This PR is not active, but has demonstrated some pretty interesting possibilities.

It will be hard to do an accurate representation of the options due to the flexible ways they are described and added, and not easily cover all use cases (e.g. the typings will not be trivially available for parameter of an action handler). But deduced typings may be looked at again in future.

Thank you for your contributions.

For some experimental strong inferred typing see: https://github.com/commander-js/extra-typings